Conventionally, a service processor such as a baseboard management controller (BMC) has a processor and its own memory device, and standard firmware is kept in a flash memory. The firmware is loaded from the flash and the kernel boots such that a file system is copied from the flash and operation of the BMC is initialized.
In a BMC development environment, a development machine can be employed for building the sources and a target machine corresponds to the BMC platform. When modifying or debugging network configurations, once any configuration change is made, another firmware image with the changed configuration must be created and then flashed using a firmware upgrade or specific hardware program in order for all the changes to be available. This involves significant downtime. As an example, when a developer is trying to debug an application, in order to see a particular change reflected, the developer must go to the boot loader, use the network, erase the current contents in the flash, and then program the network firmware and boot the BMC again. That is, every time even a single configuration change is made or a simple debug message inserted, the developer must wait for the firmware with the changes to be flashed, a process which can take 15-30 minutes to complete.
A remote file system such as a network file system (NFS) can be used for developing BMC solutions, with the development file system kept on a server. NFS can allow for changes made from a build machine to be reflected quickly on the target system. This can reduce downtime by removing the need to write updated firmware to the BMC to verify correct operation after each individual modification and/or debugging step. Writing the updated firmware may be done by flashing the BMC firmware to a SPI, NAND, or NOR memory device. Accordingly, NFS can be used in a development environment to speed up modification and/or debugging processes. In a development environment using the NFS mode, changes can be made on a server and those changes are made visible on the client almost immediately, since the BMC remains in operation.
For booting a BMC into NFS configuration, only a boot loader is kept on the flash memory. The boot loader loads the file system from a server, wherein the root file system is located on the network. When a BMC is booted in NFS mode, the file system thereby effectively resides on a remote server such that the remote server can be utilized as a development machine.
The BMC by itself has a network stack such as an open source LINUX stack and the network stack is the core foundation for the NFS. NFS requires network support on both the client side and server side, and if the network goes down for any reason, NFS cannot be used. Accordingly, for network configurations to be changed on the server side, for example switching between the use of one network interface of a BMC to another network interface, the network must be brought down, then the network configuration changes made, and then the network brought back up again. During this process, when the network is brought down, the NFS also goes down and cannot be brought back until the BMC is rebooted.
Therefore, heretofore unaddressed needs still exist in the art to address the aforementioned deficiencies and inadequacies.